<?php
/**
 * <https://y.st./>
 * Copyright © 2017 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Process Explorer',
	'<{subtitle}>' => 'Written in <span title="Operating Systems 1">CS 2301</span> of <a href="http://www.uopeople.edu/">University of the People</a>, finalised on 2017-10-11',
	'<{copyright year}>' => '2017',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<div class="APA_title_page">
	<p>
		Process Explorer<br/>
		Alex Yst<br/>
		University of the People
	</p>
</div>
<h2>Disclaimer</h2>
<p>
	For the record, I don&apos;t like Process Explorer, I don&apos;t trust Process Explorer, and I don&apos;t recommend Process Explorer.
	Even given a choice, I would never run Process Explorer on my system.
	Furthermore, Process explorer only runs on Windows and I don&apos;t own a Windows-based machine.
	However, we were required to use it for this assignment.
	(In other words, this paper should not be in any way taken to be an endorsement of Process Explorer or the Windows operating system.)
	As I don&apos;t have access to any Windows-based machines, our fellow student, Mostapha Ramadan, was kind enough to lend me access to a virtualised Windows environment remotely.
	Without his help, this assignment would&apos;ve been impossible for me to complete, as it was so suddenly sprung on us that we needed to use this Windows-based software.
	There was no warning and no time to prepare for such an assignment for those of us that use other operating systems.
	For privacy, I&apos;ve edited Mostapha&apos;s $a[IP] address out of the screenshots.
</p>
<h2>Introduction</h2>
<p>
	Process Explorer is a utility for Windows-based machines for viewing statistics about resource usage, as well as killing and reconfiguring processes.
	These same sorts of statistics can be seen on a Linux machine, and the same sorts of actions performed.
	A Linux-based program, called <a href="https://sourceforge.net/projects/procexp/">Linux Process Explorer</a>, was developed to replicate Process Explorer&apos;s interface and capabilities, but for the most part, things are done a bit differently in the Linux world.
	We Linux-users like our software to be modular, small, and perform one job well.
	Process Explorer on the other hand is monolithic, multi-functioned, and bloated; things like it aren&apos;t the tools most of us Linux users would choose.
	It&apos;s fine for use with Windows, but it just doesn&apos;t fit the Linux style of doing things.
	For this assignment, we were asked to use Process Explorer to take a look at physical memory usage, kernel memory usage, and paging statistics.
	I&apos;ll show how this can be done with Process Explorer on Windows, but also with <code>smem</code> and <code>vmstat</code> on Linux.
	Graphical tools are often more intuitive, so it&apos;s tempting to try Linux Process Explorer, but if you&apos;re looking at memory usage like this, you&apos;re probably at least somewhat tech-savvy.
	Command line tools shouldn&apos;t scare you away.
</p>
<h2>Opening the utility</h2>
<p>
	When first opening Process Explorer, a list of running processes and information about then is shown:
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/Process_Explorer.png" alt="Process Explorer" class="framed-centred-image" width="804" height="625"/>
<p>
	The most important information here is the names of the software associated with each processes and process $a[ID]s, but a little about processor usage can be seen as well.
	Specifically, the percentage of available processor time each process is consuming is visible.
	This same sort of information is available on Linux-based systems as well.
	Using the <code>top</code> command, we can see the list of processes running on my own machine:
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/top.png" alt="Output from the `top` command" class="framed-centred-image" width="661" height="411"/>
<p>
	In addition to showing the names of the software associated with the processes and the process $a[ID]s, again, the $a[CPU] time consumption is given as a percentage of the $a[CPU]s&apos; available time.
	Also interesting, at least to me, is that <code>top</code> lists the user associated with each process.
	Seen here are three such users, <code>root</code> (the account used by the system to run privileged processes), <code>debian-tor</code> (the account used by my proxy software to isolate its own process for security reasons), and <code>yst</code> (my name is Alex Yst, and especially in computer-related contexts, I typically go by my surname).
	Running <code>top</code> on the command line will show you a continually-updating list of your top resource-consuming processes, but it only shows you as many as will fit in the window.
	To list every running process, no matter how many there are, use <code>top -b</code> instead.
	Up at the top, above the process list, we can see the total $a[CPU] usage and memory usage.
</p>
<h2>Looking at memory usage</h2>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/Process_Explorer_-_before.png" alt="Process Explorer" class="framed-centred-image" width="804" height="625"/>
<p>
	Some information on memory usage can be seen from this first window in Process Explorer, but for a more-detailed look, we need to open the system information window.
	As mentioned above, this Windows system is virtualised; it&apos;s not running a bunch of user processes, as the entire virtual machine exists purely for use with this assignment.
	Because of that, memory usage is pretty low.
	501.9 $a[MB] of physical memory was in use while running Process Explorer and nothing else.
	(Well, nothing else besides the desktop environment, the operating system, and loads of background processes that run at all times ... so actually, the system was running <strong>*a lot*</strong> of stuff.
	It wasn&apos;t anywhere near max capacity though, and could take on a heavier load if it needed to.)
	A more-precise accounting of physical memory usage is available as a number of bytes near the bottom of the window on the left side, but the summary beside the lower graph at the top gives us an easier-to-understand number of megabytes.
	This is highlighted with a magenta box in the screensot.
	From the page read data and the page file write data, we see how much memory is being paged in and out.
	These paging statistics are highlighted with a yellow box.
	As the system is mostly idle, both numbers are at zero.
	No paging is needed at the moment, and all memory in use is being held in the physical $a[RAM].
	(Well, it&apos;s being held in the virtualised system&apos;s &quot;physical&quot; $a[RAM], but that $a[RAM] is virtual; who knows what&apos;s going on with our data in the host computer?
	Our data might be being paged in and out on that level.)
	Finally, we take a look at the kernel memory usage.
	I&apos;ve highlighted these statistics with a cyan box, though truthfully, I don&apos;t know exactly what these numbers mean.
	Still, we can see how they change when we start another application.
</p>
<p>
	Like with Process Explorer, a view of running processes doesn&apos;t give us an overview of the memory usage of the entire system.
	It&apos;s time to pull out another tool.
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/smem_-_before.png" alt="Output from the `smem --abbreviate --system --totals` command" class="framed-centred-image" width="493" height="231"/>
<p>
	<code>smem</code> is one of a few tools that&apos;ll show kernel memory usage; it&apos;s not something we normally need to look at, so it&apos;s not something most tools will show us.
	Passing <code>smem</code> the <code>--abbreviate</code> flag gets it to show us the usage in bigger and easier to read units, as we&apos;d see in Process Explorer for physical memory usage near the graph at the top.
	The <code>--system</code> flag is even more important to us for this assignment, as it changed <code>smem</code>&apos;s output from being a list of processes run by the current user and some statistics about them to a categorisation of memory usage into general usage types.
	To put it simply, that flag lets us see how much memory is being used by the kernel and how much memory is being used by other things.
	The <code>--totals</code> flag isn&apos;t strictly necessary, but adds up how much memory we have at the bottom, which is kind of nice.
	Adding everything but the free memory together (or subtracting the free memory from the total memory), we get the physical memory usage.
	Here, we can see that the kernel is using 1.7 $a[GB] of $a[RAM], while the rest of the system is using 643.9 $a[MB] of memory.
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/smem_-_not_abbreviated.png" alt="Output from the `smem --system --totals` command" class="framed-centred-image" width="493" height="231"/>
<p>
	We can also leave off the <code>--abbreviate</code> flag to show the amount of memory used in bytes instead of larger units, but why would we want to do that?
	Doing so would yield number more similar to those near the bottom of the Process Explorer window though, if that was desired.
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/vmstat_-_before.png" alt="Output from the `vmstat --unit M` command" class="framed-centred-image" width="669" height="156"/>
<p>
	The <code>vmstat</code> command shows us some system information, including paging stats.
	Passing it the <code>--unit M</code> flag tells it to give us the numbers in terms of megabytes, instead of bytes, but like <code>smem</code>&apos;s <code>--abbreviate</code> flag, we could leave it out if we really wanted to see the precise number of bytes in these stats.
	For legacy reasons, <code>vmstat</code> labels paging stats as the swap stats &quot;si&quot; and &quot;so&quot; (swap in and swap out) (Tanaka, 2005), but these are actually the paging stats, and would more appropriately be labelled &quot;pi&quot; and &quot;po&quot; (page in and page out).
	As with the remote Windows system, my local Linux system isn&apos;t doing any paging.
	I&apos;ve got plenty of $a[RAM] installed and I&apos;m running a relatively light-weight system with a light-weight desktop environment: Debian 9 with $a[LXDE].
</p>
<h2>After starting a new process</h2>
<p>
	For showing memory usage on both my local Debian machine and Mostapha&apos;s remote Windows machine, I chose a cross-platform application that could be run in both environments: Firefox.
	In retrospect, it might&apos;ve been more fun to choose something more resource-hungry, such as the $a[GIMP] (an advanced image editor), but Firefox was more than enough to put a visible dent in the memory usage of the machines.
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/Process_Explorer_-_starting.png" alt="Process Explorer" class="framed-centred-image" width="804" height="625"/>
<p>
	After starting Firefox, physical memory usage goes up to 683.3 $a[MB].
	The system still had resources to spare, but there was a visible jump in $a[RAM] utilisation.
	Paging was unaffected though.
	Because the system wasn&apos;t running anywhere near its limit, there was no need for it to page anything from $a[RAM] to disk or back.
	Kernel memory usage numbers went up as well, meaning the kernel was using more memory (perhaps to keep track of the new process&apos; allocated $a[RAM] locations and stack data), but again, I&apos;m not sure what each number specifically represented.
	It&apos;s doubtful that a whole lot more memory was needed by the kernel, but at least some was.
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/smem_-_starting.png" alt="Output from the `smem --abbreviate --system --totals` command" class="framed-centred-image" width="493" height="231"/>
<p>
	On Debian, starting Firefox likewise raised the memory usage.
	Kernel usage wasn&apos;t visibly raised because we were looking at it at a high level, but had we not specified the <code>--abbreviate</code> flag, we&apos;d&apos;ve no doubt seem a small increase.
	The user space memory usage was visibly increased though, and went up to 817.6 $a[MB].
	Most of the newly-needed memory went directly to the process, not to the kernel.
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/vmstat_-_starting.png" alt="Output from the `vmstat --unit M` command" class="framed-centred-image" width="669" height="156"/>
<p>
	<code>vmstat</code> shows us that paging still wasn&apos;t needed to keep the newly-running Firefox process operational.
	Like the remote Windows system, the local Debian system had resources to spare.
</p>
<h2>After running for about a minute</h2>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/Process_Explorer_-_during.png" alt="Process Explorer" class="framed-centred-image" width="804" height="625"/>
<p>
	After the process had been active a while on Windows, physical memory usage went down a bit, to 669 $a[MB].
	This was likely due to slight fluctuations in memory usage, and might&apos;ve gone back up if given time.
	That said, start-up activity was then complete and no new task (such as retrieving and rendering a page) had been given to it.
	Now idle, Firefox might not&apos;ve needed as much memory.
	Kernel memory numbers went up a bit though.
	Paging was predictably unaffected.
	There wasn&apos;t any particular reason why the system would need to start paging things in and out of memory now.
	It was difficult to get quick screenshots on Windows though, so the start-up screenshot came a bit late.
	Much of the start-up had been completed before the screen could be captured, so memory usage was given time to hit its peak, so it could tapper off a bit by the time a minute had passed.
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/smem_-_during.png" alt="Output from the `smem --abbreviate --system --totals` command" class="framed-centred-image" width="493" height="231"/>
<p>
	On Debian, memory usage went up slightly to 822.2 $a[MB] after a minute.
	Likely, the increase came from the quick stat grab; Firefox hadn&apos;t finished loading everything into memory yet, so memory usage still needed to go up.
	It could also be that the Debian system is keeping more in memory than Windows for some reason.
	It&apos;s important to note that memory usage isn&apos;t a bad thing as long as there&apos;s no paging.
	Unused $a[RAM] is $a[RAM] that isn&apos;t doing anything to help you or your computer in any way.
	Kernel memory usage predictably didn&apos;t change in any noticeable way.
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/vmstat_-_during.png" alt="Output from the `vmstat --unit M` command" class="framed-centred-image" width="669" height="156"/>
<p>
	Like with the remote Windows system, the local Debian machine&apos;s resources were underutilised, so no paging was occurring.
</p>
<h2>After shutting down the process</h2>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/Process_Explorer_-_after.png" alt="Process Explorer" class="framed-centred-image" width="804" height="625"/>
<p>
	After shutting down the Firefox in Windows, physical memory usage dropped to 500.6 $a[MB], which was about where it&apos;d been before starting Firefox in the first place.
	That was to be expected, as the system reclaimed the memory previously used by Firefox.
	Memory usage was slightly <strong>*lower*</strong> though.
	Likely, Running Firefox didn&apos;t cause this, and it was some other background process that&apos;d given up allocated memory as well.
	Kernel memory usage numbers were different than before starting Firefox, with a couple numbers being higher and one being lower.
	Again, we didn&apos;t cover in class what those numbers even mean.
	Paging was predictably unaffected.
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/smem_-_after.png" alt="Output from the `smem --abbreviate --system --totals` command" class="framed-centred-image" width="493" height="231"/>
<p>
	On Debian, closing Firefox likewise dropped memory usage.
	Kernel memory had no noticeable changes, but user space memory usage dropped to 644.6 $a[MB], just above what it&apos;d been before we started.
	Again, I suspect a background process was to blame for the slight fluctuation, as with the Windows setup.
</p>
<img src="/img/CC_BY-SA_4.0/y.st./coursework/CS2301/vmstat_-_after.png" alt="Output from the `vmstat --unit M` command" class="framed-centred-image" width="669" height="156"/>
<p>
	Like throughout the rest of this exercise, on both systems, the paging was unaffected.
</p>
<h2>Conclusion</h2>
<p>
	There&apos;s not much to take from this except what we already know: processes require memory to run.
	The operating system allocates free memory to processes when they start and during their lifespan, and when those processes terminate, the operating system reclaims and frees that memory.
	Some memory can be reclaimed by the system when a process is done with it without the process terminating, but the bulk of memory used will likely remain in use until the end of the process.
	After all, the software itself that creates the process even needs to be loaded into memory.
	Until the process is gone, the memory containing the program cannot be freed.
	Even that aside, most programs need memory to store state information related to the operation of the software.
</p>
<div class="APA_references">
	<h2>References:</h2>
	<p>
		Tanaka, B. K. (2005, October 31). Monitoring Virtual Memory with vmstat | Linux Journal. Retrieved from <a href="https://www.linuxjournal.com/article/8178"><code>https://www.linuxjournal.com/article/8178</code></a>
	</p>
</div>
END
);
